The present invention relates to asset management systems. More particularly, the present invention relates to methods and apparatus for locking and unlocking multiple instances of animation assets by version or by label during rendering.
Throughout the years, movie makers have often tried to tell stories involving make-believe creatures, far away places, and fantastic things. To do so, they have often relied on animation techniques to bring the make-believe to “life.” Two of the major paths in animation have traditionally included, drawing-based animation techniques and stop motion animation techniques.
Drawing-based animation techniques were refined in the twentieth century, by movie makers such as Walt Disney and used in movies such as “Snow White and the Seven Dwarfs” (1937) and “Fantasia” (1940). This animation technique typically required artists to hand-draw (or paint) animated images onto a transparent media or cels. After painting, each cel would then be captured or recorded onto film as one or more frames in a movie.
Stop motion-based animation techniques typically required the construction of miniature sets, props, and characters. The filmmakers would construct the sets, add props, and position the miniature characters in a pose. After the animator was happy with how everything was arranged, one or more frames of film would be taken of that specific arrangement. Stop motion animation techniques were developed by movie makers such as Willis O'Brien for movies such as “King Kong” (1933). Subsequently, these techniques were refined by animators such as Ray Harryhausen for movies including “Mighty Joe Young” (1948) and Clash Of The Titans (1981).
With the wide-spread availability of computers in the later part of the twentieth century, animators began to rely upon computers to assist in the animation process. This included using computers to facilitate drawing-based animation, for example, by painting images, by generating in-between images (“tweening”), and the like. This also included using computers to augment stop motion animation techniques. For example, physical models could be represented by virtual models in computer memory, and manipulated.
One of the pioneering companies in the computer-generated animation (CG animation) industry was Pixar. Pixar is more widely known as Pixar Animation Studios, the creators of animated features such as “Toy Story” (1995) and “Toy Story 2” (1999), “A Bugs Life” (1998), “Monsters, Inc.” (2001), “Finding Nemo” (2003), “The Incredibles” (2004), and others. In addition to creating animated features, Pixar developed computing platforms specially designed for CG animation, and CG animation software now known as RenderMan®. RenderMan® was particularly well received in the animation industry and recognized with two Academy Awards®. RenderMan® renders images based upon conceptual “software assets” including geometric scene descriptors including references to object models.
Typically, scenes to be rendered are specified (assembled) by one or more users (e.g. animators, lighters, etc.). These scenes include descriptions of the objects, camera angles, lighting sources, and the like. The scene data file (also known as a scene descriptor file) that describes the entire scene is typically very large, on the order of gigabytes. Because the sizes of typical scene descriptor files are typically large, Pixar developed an internal technique for segmenting a scene descriptor file from one large file into a series of smaller files. As described in the co-pending application described above, Pixar developed and used the concept of “hook set” files and references to “hook files” to describe a scene. Accordingly, a typical scene is actually composed of a number of separate data files. Generally, logical assets, such as a scene, a shot (a group of scenes), an object, and the like are themselves composed of any number of separate assets.
The inventors of the present invention have recognized that when rendering a lengthy animated feature, such as a feature film, tens or hundreds of related frames need to be rendered. This process typically takes a substantial period of time, even when parallelized. However, during the time which one frame takes to render, it is possible for different users to install new versions of one or more assets (e.g. objects to be rendered) referenced in the frame. Because frames are not necessarily rendered chronologically, a change to an object, such as a new version of an object, may result in a visual discontinuity, or a “pop” if the new object looks different from the old one in the various scenes. Alternatively, the inclusion of a new version of an object may cause the rendering engine to terminate early with an error.
The inventors of the present invention have recognized that it is not typically feasible to prevent users from modifying a logical asset (e.g. a sequence, a shot, an object) throughout the rendering process. This is because, scenes or shots of animation are finalized at different times, and it would be very inefficient to begin rendering scenes or shots only when all of the scenes or shots have been finished. Accordingly, the inventors have recognized that methods for providing support for multiple simultaneous version of animation assets.
The inventors of the present invention have also recognized that after a shot or sequence has been rendered and that render approved, it is very common for images to need to be re-worked after being approved to make them ready for “film-out.” However, versions of the assets that were used often no longer exist because they were replaced with “improved” versions of the assets, for example. Accordingly, it is extremely difficult to re-render or replicate previously rendered images. Further, in practice, the Inventors have recognized that logical animation assets (e.g. characters, props, sets, and the like) are used in many different scenes and shots in a feature, and the logical assets are often changed to meet the needs of the specific shots. Accordingly, a “latest” versions of a logical asset may not be the version that is desired. Therefore, the inventors have recognized that methods for identifying and managing different versions of objects that are used for specific scenes or shots are required.
Some techniques that the inventors have considered to address the above problems have included enforcing a strictly linear production pipeline for animation assets. Drawbacks to this technique include that the increased time and cost to develop assets because only one version of an object can exist at a time. Another drawback is that the added delays may force changes to the storyline. In contrast, the inventors believe a parallel development effort would provide for more of an iterative development where some productions pipelines are unaffected by stalls in other production pipelines.
Another technique considered includes making and storing local copies of logical assets before rendering the scene. Drawbacks to this technique include that when there are a large number of assets, and a large number of scenes, storing copies of assets for each scene in local directories requires an wasteful amount of memory. Additionally copies are often poorly tracked and not stored in a centralized location for easy access. Yet another drawback is that such a technique would be very slow and expensive when applied to thousands of CPUs in a large render farm because of the amount of data that would be stored and passed back and forth. Yet another disadvantage is that this technique does not address the replicability problem described above.
Another technique the inventors have considered included preventing users from installing new versions of objects during the rendering process. Disadvantages to this technique include that would cause an expensive and large bottleneck in the production pipeline. For example, because rendering of certain shots or scenes may last for hours and days, this technique would lock out other users from installing versions of objects for their shots or scenes. Other users would have to wait until small windows of opportunity between renderings to install new versions of objects. Yet another drawback includes that it is inefficient to have users who are attempting to install new versions of objects be made aware of all the other users of the same object and their rendering schedules. Still another disadvantage is that this technique does not address the replicability problem described above.
A technique the inventors considered to address the issue of replicability is through the use of timestamps and traditional version control of assets. However, disadvantages to these techniques includes that different rendering processes can be performed at the same time through the use of local copies of the asset during the development process. Because, no versioning control is provided until an asset is checked-in, replicating of scenes before check-in is not supported. Additionally, when such assets are checked-in, different versions of an object from different users may have the same timestamp or have an out-of-order version number (e.g. version 1.2 includes changes in version 1.3, but version 1.3 lacks changes made in version 1.2.) As such, no version control data exists between the different users. Other drawbacks includes that traditional version control techniques do not support the animation production process because of different assumptions about build stability and uniformity, branching and branching support, mechanisms for deployment, and the like. Yet another drawback to this approach includes that, rolling back of changes to objects is slow, and computationally expensive (i.e. burdens the CPU).
Still another technique considered by the inventors has been through the use of variants. Drawbacks to this technique includes that variants of models as versions of models pollutes the semantics of version control. The inventors consider true variants or branches as an asset based-on another asset, but with a different pipeline purpose or pipeline approach. In contrast, a version is an instance of an asset which is part of a linear progression typically used for development of a variant. Accordingly, this approach also had disadvantages.
Accordingly what is desired is an improved method and apparatus for asset management, without the drawbacks described above.